Method and apparatus for flexibly supporting services in wireless communication system

ABSTRACT

The disclosure relates to a communication technique for combining, with IoT technology, a 5 th  generation (5G) communication system or a pre-5G communication system for supporting a higher data transmission rate after a 4 th  generation (4G) system such as long-term evolution (LTE), and to a system therefor. The disclosure may be applied to intelligent services (e.g., a smart home, a smart building, a smart city, a smart car or connected car, healthcare, digital education, retail business, security and safety-related service, etc.), based on a 5G communication technology and an IoT-related technology. Various embodiments may provide a method for managing context of a terminal in a mobile communication system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on and claims priority under 35 U.S.C. § 119to Korean Patent Application No. 10-2019-0055889 filed on May 13, 2019,Korean Patent Application No. 10-2019-0066626 filed on Jun. 5, 2019, andKorean Patent Application No. 10-2019-0122217 filed on Oct. 2, 2019 inthe Korean Intellectual Property Office, the disclosures of which areherein incorporated by reference in their entirety.

BACKGROUND 1. Field

The disclosure relates to a technique for managing an identifier of aterminal and status information (context) thereof in a mobilecommunication system.

2. Description of Related Art

To meet the demand for wireless data traffic having increased sincedeployment of 4G communication systems, efforts have been made todevelop an improved 5G or pre-5G communication system. Therefore, the 5Gor pre-5G communication system is also called a “Beyond 4G Network” or a“Post LTE System”.

The 5G communication system is considered to be implemented in higherfrequency (mmWave) bands, e.g., 60 GHz bands, so as to accomplish higherdata rates. To decrease propagation loss of the radio waves and increasethe transmission distance, the beamforming, massive multiple-inputmultiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna,an analog beam forming, large scale antenna techniques are discussed in5G communication systems.

In addition, in 5G communication systems, development for system networkimprovement is under way based on advanced small cells, cloud radioaccess networks (RANs), ultra-dense networks, device-to-device (D2D)communication, wireless backhaul, moving network, cooperativecommunication, coordinated multi-points (CoMP), reception-endinterference cancellation and the like.

In the 5G system, hybrid FSK and QAM modulation (FQAM) and slidingwindow superposition coding (SWSC) as an advanced coding modulation(ACM), and filter bank multi carrier (FBMC), non-orthogonal multipleaccess (NOMA), and sparse code multiple access (SCMA) as an advancedaccess technology have also been developed.

The 5G system is considering supports for more various services ascompared to the conventional 4G system. For example, the mostrepresentative service may include a ultrawide band mobile communicationservice (enhanced mobile broad band (eMBB)), a ultrahigh reliable/lowlatency communication service (ultra-reliable and low latencycommunication (URLLC)), a massive device-to-device communication service(massive machine type communication (mMTC)), and a next-generationbroadcast service (evolved multimedia broadcast/multicast service(eMBMS)). A system providing the URLLC service may be referred to as aURLLC system, and a system providing the eMBB service may be referred toas an eMBB system. The terms “service” and “system” may beinterchangeably used.

Among these services, the URLLC service that is a new service underconsideration in the 5G system in contrast to the existing 4G systemrequires to meet ultrahigh reliability (e.g., packet error rate of about10-5) and low latency (e.g., about 0.5 msec) conditions as compared tothe other services. To meet these strict conditions required therefor,the URLLC service may need to apply a shorter transmission time interval(TTI) than the eMBB service, and various operating scheme employing thesame are now under consideration.

The Internet, which is a human centered connectivity network wherehumans generate and consume information, is now evolving to the Internetof things (IoT) where distributed entities, such as things, exchange andprocess information without human intervention. The Internet ofeverything (IoE), which is a combination of the IoT technology and thebig data processing technology through connection with a cloud server,has emerged. As technology elements, such as “sensing technology”,“wired/wireless communication and network infrastructure”, “serviceinterface technology”, and “security technology” have been demanded forIoT implementation, a sensor network, a machine-to-machine (M2M)communication, machine type communication (MTC), and so forth have beenrecently researched.

Such an IoT environment may provide intelligent Internet technologyservices that create a new value to human life by collecting andanalyzing data generated among connected things. IoT may be applied to avariety of fields including smart home, smart building, smart city,smart car or connected cars, smart grid, health care, smart appliancesand advanced medical services through convergence and combinationbetween existing information technology (IT) and various industrialapplications.

In line with this, various attempts have been made to apply 5Gcommunication systems to IoT networks. For example, technologies such asa sensor network, machine type communication (MTC), andmachine-to-machine (M2M) communication may be implemented bybeamforming, MIMO, and array antennas. Application of a cloud radioaccess network (RAN) as the above-described big data processingtechnology may also be considered an example of convergence of the 5Gtechnology with the IoT technology.

The above information is presented as background information only toassist with an understanding of the disclosure. No determination hasbeen made, and no assertion is made, as to whether any of the abovemight be applicable as prior art with regard to the disclosure.

SUMMARY

An embodiment proposes a structure in which data processed by networkfunctions (NFs) is separated and stored in order to increasecommunication efficiency and improve customer service quality in a 5Gsystem. In addition, an embodiment proposes an identifier (ID)processing method to solve an ID conflict issue between NFs, which mayoccur when introducing the above structure.

The technical subjects pursued in the disclosure may not be limited tothe above mentioned technical subjects, and other technical subjectswhich are not mentioned may be clearly understood, through the followingdescriptions, by those skilled in the art to which the disclosurepertains.

In accordance with an aspect of the disclosure, a method performed by anaccess and mobility management function (AMF) entity in a wirelesscommunication system is provided. The method includes receiving, from afirst session management function (SMF) entity, a first message totransfer a session management (SM) context to a second SMF entity;transmitting, to the second SMF entity, a second message for requestingthe second SMF entity to receive the SM context from the first SMFentity; starting a timer upon transmitting the second message; andreceiving, from the second SMF entity, a third message as a response tothe second message before expiring the timer.

In one embodiment, the method further comprises determining that a SMcontext transfer procedure is failed in case that the timer expiresbefore receiving the third message.

In one embodiment, the first message includes information on indicatingof transferring the SM context.

In one embodiment, the method further comprises receiving, from aterminal, a service request message before receiving the third message;and delaying a transaction related to the SM context until receiving thethird message.

In one embodiment, the method further comprises receiving, from ananother AMF entity, a user equipment (UE) context transfer requestmessage before receiving the third message; and delaying a transactionrelated to the SM context until receiving the third message.

In one embodiment, the first message comprises aNsmf_PDUSession_SMContextStatusNotify message, the second messagecomprises a Nsmf_PDUSession_CreateSMContext request message, and thethird message comprises a Nsmf_PDUSession_CreateSMContext responsemessage.

In one embodiment, the transmitting the second message furthercomprising: selecting the second SMF entity based on the first message.

The disclosure also provides an access and mobility management function(AMF) in a wireless communication system. The AMF entity includes: atransceiver; and a controller configured to: receive, from a firstsession management function (SMF) entity via the transceiver, a firstmessage to transfer a session management (SM) context to a second SMFentity, transmit, to the second SMF entity via the transceiver, a secondmessage for requesting the second SMF entity to receive the SM contextfrom the first SMF entity, start a timer upon transmitting the secondmessage, and receive, from the second SMF entity via the transceiver, athird message as a response to the second message before expiring thetimer.

In the case of applying an embodiment, it is possible to freelydistribute throughput by sharing context of a terminal between NFs andto support customer services without sacrificing quality by enabling theservice provided by a faulty NF to be taken over by another NF. Inaddition, in the case of applying an embodiment, IDs used by NFs sharingcontext with each other may be determined and managed according to thesystem capacity/performance and customer service characteristics,thereby preventing service errors or degradation of customer servicequality caused by conflict of IDs.

Effects obtainable from the disclosure may not be limited to the abovementioned effects, and other effects which are not mentioned may beclearly understood, through the following descriptions, by those skilledin the art to which the disclosure pertains.

Before undertaking the DETAILED DESCRIPTION below, it may beadvantageous to set forth definitions of certain words and phrases usedthroughout this patent document: the terms “include” and “comprise,” aswell as derivatives thereof, mean inclusion without limitation; the term“or,” is inclusive, meaning and/or; the phrases “associated with” and“associated therewith,” as well as derivatives thereof, may mean toinclude, be included within, interconnect with, contain, be containedwithin, connect to or with, couple to or with, be communicable with,cooperate with, interleave, juxtapose, be proximate to, be bound to orwith, have, have a property of, or the like; and the term “controller”means any device, system or part thereof that controls at least oneoperation, such a device may be implemented in hardware, firmware orsoftware, or some combination of at least two of the same. It should benoted that the functionality associated with any particular controllermay be centralized or distributed, whether locally or remotely.

Moreover, various functions described below can be implemented orsupported by one or more computer programs, each of which is formed fromcomputer readable program code and embodied in a computer readablemedium. The terms “application” and “program” refer to one or morecomputer programs, software components, sets of instructions,procedures, functions, objects, classes, instances, related data, or aportion thereof adapted for implementation in a suitable computerreadable program code. The phrase “computer readable program code”includes any type of computer code, including source code, object code,and executable code. The phrase “computer readable medium” includes anytype of medium capable of being accessed by a computer, such as readonly memory (ROM), random access memory (RAM), a hard disk drive, acompact disc (CD), a digital video disc (DVD), or any other type ofmemory. A “non-transitory” computer readable medium excludes wired,wireless, optical, or other communication links that transporttransitory electrical or other signals. A non-transitory computerreadable medium includes media where data can be permanently stored andmedia where data can be stored and later overwritten, such as arewritable optical disc or an erasable memory device.

Definitions for certain words and phrases are provided throughout thispatent document, those of ordinary skill in the art should understandthat in many, if not most instances, such definitions apply to prior, aswell as future uses of such defined words and phrases.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure and itsadvantages, reference is now made to the following description taken inconjunction with the accompanying drawings, in which like referencenumerals represent like parts:

FIG. 1 illustrates a diagram of the structure of an SBA-based 5G systemaccording to an embodiment;

FIG. 2 illustrates a diagram of the separation structure of NFs andcontext according to an embodiment;

FIG. 3 illustrates a diagram of an example of the operation of a 5Gsystem including a terminal, a base station, and a core according to anembodiment;

FIG. 4 illustrates a diagram of another example of the operation of a 5Gsystem (a terminal, a base station, and NFs) according to an embodiment;

FIG. 5 illustrates a diagram of an example of effectively managingtemporary identifiers even in the structure in which a 5G system isdynamically changed according to an embodiment;

FIG. 6 illustrates a diagram of a method of dividing a pool ofidentifiers shared by an NF set into chunk units and assigning,managing, and collecting the same in units of chunks, instead ofrequesting and assigning temporary identifiers each time a transactionis processed according to another embodiment;

FIG. 7 illustrates a diagram of a process in which a specific NF returnsan assigned ID of which the use is terminated according to anembodiment;

FIG. 8 illustrates a diagram of a method of selecting a target NF inconsideration of the capacity of an NF receiving context when providinga service by exchanging context between context storages or NFsaccording to an embodiment;

FIG. 9 illustrates a diagram of a method of managing context in an NFaccording to an embodiment;

FIG. 10 illustrates a diagram of a method for preventing malfunction andoverload due to context transfer and change of an NF according to anembodiment;

FIG. 11 illustrates the detailed operation of an AMF according to anembodiment;

FIG. 12 illustrates the detailed operation of an AMF according to anembodiment;

FIG. 13 illustrates a diagram of the configuration of a terminalaccording to the disclosure; and

FIG. 14 illustrates a diagram of the configuration of a network entityaccording to the disclosure.

DETAILED DESCRIPTION

FIGS. 1 through 14, discussed below, and the various embodiments used todescribe the principles of the present disclosure in this patentdocument are by way of illustration only and should not be construed inany way to limit the scope of the disclosure. Those skilled in the artwill understand that the principles of the present disclosure may beimplemented in any suitably arranged system or device.

Hereinafter, the operation principle of the disclosure will be describedin detail in conjunction with the accompanying drawings. In thefollowing description of the disclosure, a detailed description of knownfunctions or configurations incorporated herein will be omitted when itmay make the subject matter of the disclosure rather unclear. The termswhich will be described below are terms defined in consideration of thefunctions in the disclosure, and may be different according to users,intentions of the users, or customs. Therefore, the definitions of theterms should be made based on the contents throughout the specification.

In the following description, terms for identifying access nodes, termsreferring to network entities, terms referring to messages, termsreferring to interfaces between network entities, terms referring tovarious identification information, and the like are illustratively usedfor the sake of convenience. Therefore, the disclosure is not limited bythe terms as used below, and other terms referring to subjects havingequivalent technical meanings may be used.

In the following description, the disclosure uses terms and namesdefined in 3rd generation partnership project long term evolution (3GPPLTE) standards for the convenience of description. However, thedisclosure is not limited by these terms and names, and may be appliedin the same way to systems that conform other standards.

Meanwhile, in describing embodiments, a node/NF having functions ofseparating, storing, and retrieving UE information (UE context)processed/managed by an NF will be called a “context storage” that has aconcept including an unstructured data storage function (UDSF) that isan NF for storing/sharing unstructured data and a context transferstorage function (CTSF) that is an NF for storing/transmitting context.

Meanwhile, in the disclosure, the term “service” will be used to referto an “NF service” in which a specific communication device (or NF)processes a request by another communication device (or NF), and a“customer service” will be separately used in order to specificallyindicate a service provided to an end-user.

A new system structure and protocol were required to support variousservices of 5G, and then 3GPP decided to introduce a new technologycalled “service-based architecture (SBA)”.

FIG. 1 illustrates a diagram of the structure of an SBA-based 5G systemaccording to an embodiment.

Referring to FIG. 1, an access and mobility management function (AMF)120 is a network function (NF) that manages access and mobility of a UE110 in a wireless network. A session management function (SMF) 130 is anNF that manages a session for the UE 110, and session informationincludes QoS information, charging information, and information onpacket processing. A user plane function (UPF) 125 is an NF thatprocesses user plane traffic and is controlled by the SMF 130. Althoughnot shown in FIG. 1, the 5G system may include a UDSF, and the UDSF isan NF that stores unstructured data. Any type of data may be stored orretrieved at a request by the NF.

FIG. 2 illustrates a diagram of the separation structure of NFs andcontext according to an embodiment.

Referring to FIG. 2, in an embodiment, data (UE context) in the NF isseparated from the NF and stored in a separate context storage, and aset of NFs that may share and use the same is referred to as an “NFset”. Depending on an implementation environment, a specific NF may beoperated/managed in the form of an NF instance, and the subject matterof the disclosure may be applied to an environment of managing andoperating any one of the NF and the NF instance. In addition, the NF maybe replaced with an NF service in the case of the operation in units ofNF services, instead of implementation/realization in units of NFs.Accordingly, the term “NF” in the disclosure may encompass an NFinstance, an NF service, and an NF service instance. If multiple NF setscoexist, distinct identifiers or names may be assigned to the respectiveNF sets in order to distinguish therebetween, and even if NFs in the NFset operate by sharing context with each other, the respective NFs maybe assigned with different identifiers/names for management/operationthereof.

FIG. 3 illustrates a diagram of an example of the operation of a 5Gsystem including a terminal, a base station, and a core according to anembodiment.

Referring to FIG. 3, step 301 may be performed in the case where arequester 382 making a request to any NF 383 included in an NF set for aservice is a radio access network (RAN) (base station), and a radioresource control (RRC) connection is established between a UE 381 andthe RAN 382 in order to transmit and receive signaling/data using radioresources.

In step 305, the requester 382 makes a request to the NF 383 for aspecific NF service. If the requester is the RAN 382, the target NF 383may be an AMF. In this case, the requester 382 may specify and transmita receiver 383 of the request. If the request is transmitted to the NFset without specifying a specific NF, any NF in the NF set may receivethe request.

In step 309, the receiving NF 383 performs an operation according to theNF service request. The receiving NF 383 identifies whether or not therequested NF service requires UE context that is pre-cached in the NFset, that is, in the NF or the context storage 384. If information ispre-cached in the NF, the cached information may be directly used, sothat steps 313 to 321 may be omitted.

If the UE context cached in the context storage 384 is required, the NF383 makes a request to the context storage 384 for retrieving thecontext in step 313. In this case, if the context storage 384 is a UDSF,a “Nudsf_UnstructuredDataManagement_Query service (request)” may be usedfor the context retrieval request, and the request message may include adata identifier for identifying data to be retrieved. If the NF 383 isaware of a correct data identifier, the identifier capable ofidentifying data may include a value corresponding thereto. Otherwise,the identifier may include an identifier of a specific UE. Theidentifier of a specific UE (subscriber) includes a subscriptionpermanent ID (SUPI) (an IMSI or NAI type) or a unique temporaryidentifier in a specific NF set {pre-assigned as one of a 5G-globallyunique temporary identifier (GUTI), an internet protocol (IP) address, atunnel endpoint ID (TED), a flow ID, an application/service ID, acharging ID, and the like}.

In step 317, the context storage 384 searches for data to be retrievedaccording to the request by the NF 383 and transmits, to the NF 383, aresponse thereto in step 321. If the request is valid, that is, if thecontext storage 384 is able to retrieve valid context using theidentifier included in the request message, the response messagetransmitted in step 321 includes the corresponding context. In thisprocess, the context storage 384 may consider the identifier included inthe request (a data identifier or a UE/subscriber identifier) and thetype of the NF 383 making the request (a type such as AMF, SMF, etc.) inorder to check the validity of the request by the NF 383 and find thecontext to be retrieved. In the case where the context storage 384 is aUDSF, the response corresponds to a response of“Nudsf_UnstructuredDataManagement_Query” service. If the request in step313 is made using an identifier of a UE (subscriber), instead of using aspecific data identifier, and if a specific data identifier ispre-assigned to the context storage 384, the response transmitted instep 321 includes the data identifier. In addition, upon receiving theresponse, the NF 383 may store the data identifier, and may use thecorresponding data identifier when making a request to the contextstorage 384 in the future. According to this, it is possible to reducethe time taken for the context storage 384 to search for the storedcontext using the UE (subscriber) identifier or to reduce the load onthe context storage 384 to do so.

In step 325, the procedure/transaction requested in step 305 isprocessed using the corresponding context. In the embodiment, theprocedure/transaction includes a processing operation in a specific NF,and further includes an operation of transmitting/receiving a messageand requesting services by interworking with another NF accordingthereto.

In the case where the UE context is required to be updated or new UEcontext is required to be stored in the context storage 384 by arequest, the NF 383 makes a request to the context storage 384 forstoring/updating context in step 329, and the request includesidentifiers of the new context and data or identifiers of the contextand data to be updated. If the context storage 384 is a UDSF, thecorresponding operation may be performed using services“Nudsf_UnstructuredDataManagement_Create (storage)” and“Nudsf_UnstructuredDataManagement_Update (update)”. In the case ofupdate, if the NF 383 is explicitly aware of the data identifier orreceives the same, the NF 383 may perform updating the UE context usingthe corresponding data identifier. In addition, in the case of “create”,the NF 383 may transmit, to the context storage 384, the UE (subscriber)identifier and the context to be stored.

In step 333, the context storage 384 may store the context transmittedfrom the NF 383, and if a new data identifier is required to be created(generated) (in the case of using a UE or subscriber identifier in step329), the context storage 384 may create a new data identifier, and maytransmit the same to the NF 383 through a response in step 337.

The NF 383 and other nodes 381 and 382 process the remainingprocedures/transactions in step 341. If a new temporary ID (one or moreof a 5G-GUTI, a TED, and an IP address) for a UE (subscriber) isassigned through the corresponding procedure/transaction, the ID istransmitted to the UE 381, and the UE 381 stores the same for use insubsequent procedures.

The above embodiment has described a method of grouping multiple NFsinto an NF set and separating/sharing contexts. When performing aprocess of providing connectivity to a user through a 5G system, varioustypes of temporary identifiers are assigned. Although the embodimentsare described based on the following temporary identifiers, the subjectmatter of the disclosure may be applied to the case ofassigning/managing any type of temporary identifier used in thecommunication system.

-   -   5G-GUTI: This is a globally unique temporary identifier and        includes an identifier GUAMI of an AMF serving the UE and an MME        temporary mobile subscriber identity (M-TMSI) assigned to the        UE. In one AMF set, the M-TMSI must be uniquely assigned to each        UE.    -   TEID: This is an endpoint ID for distinguishing GTP {general        packet radio system (GPRS) tunneling protocol} tunnels for        transmitting packets between communication equipments (between a        base station and an NF or between NFs) (especially, UPF), and is        required to be uniquely assigned within the IP used by the NF.    -   UE IP address: This is an IP address assigned to a UE when the        UE uses IP communication, and must be uniquely assigned to each        UE within one IP domain.    -   Flow ID: This is an identifier assigned to identify and control        specific traffic flow.    -   Application ID: This is an identifier assigned to identify a        specific service application.    -   Analytic ID: This is an identifier assigned to collect/analyze        information on an NW, and may be used in a N/W data analytic        function (NWDAF).    -   Background data transfer reference ID: This is an identifier        used to transmit data to a UE in the background.    -   Charging data record (CDR) ID: This is an identifier used to        control specific charging information.

If the NF assigns a temporary identifier to a specific UE (subscriber),uniqueness must be assured according to a certain condition, and if theuniqueness is not satisfied, an error occurs, thereby degrading thequality of service or requiring an error recovery process. Unlike thesystem in which all the resources inside one NF are consumed, in thestructure described in the above embodiment, NFs in an NF set sharecontext, and an NF serving a single UE (subscriber) may be changed atany time in the same set. In such a system, since the entire pool oftemporary identifiers is also shared by the NFs, there may be a problemin that two NFs simultaneously assign one temporary identifier to twoUEs (subscribers).

FIG. 4 illustrates a diagram of another example of the operation of a 5Gsystem (a UE, a base station, and NFs) according to an embodiment.

Referring to FIG. 4, reference numeral 401 denotes an interworking nodethat may request/trigger NF services in a specific NF, and may be a UE,a RAN (base station), or another NF.

Reference numeral 402 represents an NF for providing a communicationfunction, and includes an NF defined in the 3GPP standard and a networkequipment similar thereto. If a specific NF is implemented/operated inthe form of an instance, the NF may be replaced with an NF instance. TheNF may be replaced with an NF service in the case of the operation inunits of NF services, instead of implementation/realization in units ofNFs.

A configuration server (conf. server) 403 is a server providing afunction of managing/configuring communication equipments (a RAN, an NF,etc.), and is generally called an “element management system (EMS)” oran “operation and maintenance (OAM) system”. A virtualized networkfunction manager (VNFM)/orchestrator 404 is a system thatconfigures/manages NFs in a virtualized system. In the disclosure, anembodiment will be described on the assumption that two systems areseparated, but the two systems may be integrated into one, and in thiscase, the exchange of messages between the two systems may be omitted,or may be processed through an internal procedure.

In step 431, the NF 402 is initially installed or configured.

In step 434, the VNFM/orchestrator 404 informs the configuration server403 of the size of the NF (typically corresponding to the maximumcapacity) (a value such as the number of concurrently processiblesubscribers or the number of sessions, a value indicating the relativecapacity, or the like) and the size of the NF set (the number of NFsincluded in the NF set, the maximum capacity of the entire set, or thelike).

In step 437, the configuration server 403 may divide the entire pool oftemporary identifiers shared by the NF set by the received size of theNF/NF set, thereby determining an available identifier to be used foreach NF, and may transmit information assigned to each NF 402. Availableidentifier information may be transmitted to the NF 402 according to thetype thereof, and the configuration server 403 may transmit, to the NF402, a start value of the temporary identifier, a form of the totalnumber or a range of the temporary identifiers (values indicating astart to an end), or a list of all assigned identifiers. When managingthe temporary identifier, the configuration server 403 may reserve somesections in consideration of changes in the NW configuration (the sizeof an NF, the size of a set, etc.) in the future, and may performinitial assignment using the remaining sections.

In step 441, the NF 402 stores a pool of temporary identifiers to beused by the NF 402 according to the received information.

The UE (or RAN or another NF) 401 makes a request to the NF 402 for aspecific NF service in step 445, and if a temporary identifier isrequired to be assigned to each UE (subscriber), the NF 402 may assignan identifier from the stored pool in step 449. In step 453, the NF 402may respond to the UE (or RAN or another NF) 401.

The above embodiment may be utilized in the case where multiple NFs areincluded in an NF set. If the number of NFs in the NF set is dynamicallychanged (if a scaling-size changes due to malfunction or load), or ifthe size of each NF is changed, it is difficult to change the pool ofidentifiers to conform to the situation.

FIG. 5 illustrates a diagram of an example of effectively managingtemporary identifiers even in the structure in which a 5G system isdynamically changed according to an embodiment.

Referring to FIG. 5, reference numeral 501 denotes an interworking nodethat may request/trigger NF services in a specific NF, and may be a UE,a RAN (base station), or another NF.

Reference numeral 502 represents an NF for providing a communicationfunction, and includes an NF defined in the 3GPP standard and a networkequipment similar thereto. If a specific NF is implemented/operated inthe form of an instance, the NF may be replaced with an NF instance. TheNF may be replaced with an NF service in the case of the operation inunits of NF services, instead of implementation/realization in units ofNFs.

An ID management server 503 is a server providing a function of managingan identifier pool of all NFs. The ID management server 503 may beconfigured as a separate function (NF), or may be configured as adetailed function provided by the context server while being integratedwith the context server described in the above embodiment.

Step 531 means that the interworking node (UE/RAN/NF) 501 and the NF 502are in the state capable of exchanging messages with each other andperforming interworking operations.

In step 535, the UE or interworking NF 501 makes a request to the NF 502for an NF service. The request for an NF service by the interworking NF501 may be made in the process of processing a service by a request of aUE, a request of a RAN, or the internal operation of an NF and a requestby another NF.

In step 539, the NF 502 processes the received transaction anddetermines whether new context needs to be created or a temporaryidentifier needs to be assigned.

In step 544, the NF 502 may transmit, to the ID management server 503, arequest for assigning an ID or creating/updating context. In this case,the NF 502 may make a request to the ID management server 503 for atemporary identifier to be assigned to the UE (subscriber). The requestmessage may include information on the type of temporary identifier tobe used. The type information may include one or more of theabove-described identifiers such as an M-TMSI, a 5G-GUTI, a GTP TEID,and an IP address. In addition, the NF 602 may make an explicit requestto the ID management server 503 for whether or not to applyrandomization when assigning the temporary identifier. If the IDmanagement server 503 supports services of a UDSF, the request/responsemay be processed using the services described in the above embodiment inFIG. 2.

In step 549, the ID management server 503 stores/updates the context ifa request for processing context is received, and assigns the requestedtemporary identifier. If the requested temporary identifier requiresrandomization (e.g., in the case of the 5G-GUTI or the M-TMSI), or ifseparate randomization is explicitly requested, the ID management server503 applies randomization when assigning the temporary identifier.

In step 554, the ID management server 503 transmits, to the NF 502, theassigned temporary identifier and, in the case where a request forprocessing context is received, a response to the context processing.

In step 559, the NF 502 processes the remaining procedures/transactionsusing the assigned temporary identifier.

In step 564, the assigned temporary identifier is transmitted to theinterworking node (UE/base station or interworking NF) 501, and theinterworking node 501 receiving the temporary identifier stores the samefor use in the subsequent procedures.

FIG. 6 illustrates a diagram of a method of dividing a pool ofidentifiers shared by an NF set into chunk units and assigning,managing, and collecting the same in units of chunks, instead ofrequesting and assigning temporary identifiers each time a transactionis processed according to another embodiment.

The assignment method in units of chunks is effective because signalingbetween NFs for management of identifiers is able to be reduced andbecause collisions is able to be prevented while each NF freely assignsan identifier within a chunk.

Referring to FIG. 6, reference numeral 601 denotes an interworking nodethat may request/trigger NF services in a specific NF, and may be a UE,a RAN (base station), or another NF.

Reference numeral 602 represents an NF for providing a communicationfunction, and includes an NF defined in the 3GPP standard and a networkequipment similar thereto. If a specific NF is implemented/operated inthe form of an instance, the NF may be replaced with an NF instance. TheNF may be replaced with an NF service in the case of the operation inunits of NF services, instead of implementation/realization in units ofNFs.

An ID management server 603 is a server providing a function of managingan identifier pool of all NFs. The ID management server 603 may beconfigured as a separate function (NF), or may be configured as adetailed function provided by the context server while being integratedwith the context server described in the above embodiment. The IDmanagement server 603 may be configured for each specific NF set, or maybe configured to support multiple NF sets.

Step 630 means that the interworking node (UE/RAN/NF) 601 and the NF 602are in the state capable of exchanging messages with each other andperforming interworking operations.

In step 635, the UE or interworking NF 601 makes a request to the NF 602for an NF service. The request for an NF service by the interworking NF601 may be made in the process of processing a service by a request of aUE, a request of a RAN, or the internal operation of an NF and a requestby another NF.

In step 640, the NF 602 processes the received transaction anddetermines whether or not a temporary identifier needs to be assigned.Step 635 does not necessarily precede step 640, and if assignment of theID pool is required in an initiation process for processing a servicerequest or in the general operation situation, the NF 602 may start fromstep 640.

In step 645, the NF 602 may transmit a request for ID assignment to theID management server 603. In this case, the NF 602 may make a request tothe ID management server 603 for chuck assignment of a temporaryidentifier to be assigned to the UE (subscriber). The request messagemay include information on the type of temporary identifier to be usedand a chunk size (that is, the number of IDs to be assigned). The typeinformation may include one or more of the above-described identifierssuch as an M-TMSI, a 5G-GUTI, a GTP TEID, and an IP address. In the casewhere the ID management server 603 is configured to simultaneouslysupport multiple NF sets, the NF 602 may inform the ID management server603 of the name or information of the NF set to which the NF 602 belongsusing the request message. In addition, the NF 602 may make an explicitrequest to the ID management server 603 for whether or not to applyrandomization when assigning the temporary identifier. If the IDmanagement server 603 supports services of a UDSF, the request/responsemay be processed using the services described in the above embodiment inFIG. 2, and the assignment of the ID chunk may be implemented through anoperation of creating specific context. Alternatively, a separateservice for making an explicit request to the UDSF for ID assignment maybe used.

In step 650, the ID management server 603 assigns the requestedtemporary identifier. If the requested temporary identifier requiresrandomization (e.g., in the case of the 5G-GUTI or the M-TMSI), or ifseparate randomization is explicitly requested, the ID management server603 applies randomization when assigning the temporary identifier. TheID management server 603 may accept the full size of the requestedchunk, thereby assigning the temporary identifier, or may assign asmaller chunk. Information on the chunk includes an identifier of thechunk, which will be used for management (return or the like) in unitsof chunks in the future.

In step 655, the ID management server 603 may transmit, to the NF 602,the assigned temporary identifier chunk. The ID management server 603may further transmit, to the NF 602, information on success or failureand information on the chunk size.

In step 660, the NF 602 processes the remaining procedures/transactionsusing the assigned temporary identifier.

In step 665, the assigned temporary identifier is transmitted to theinterworking node (UE/base station or interworking NF) 601, and theinterworking node 601 receiving the temporary identifier stores the samefor use in the subsequent procedures.

Meanwhile, in another embodiment, the operation of assigning/managingIDs in units of chunks may include an operation of exchanginginformation on the chunk in advance between the NF 602 and the IDmanagement server 603 and transmitting only an identifier (or index) ofthe chunk in the actual operation such as assignment/return, as well asan operation of specifying and transmitting information on theidentifiers included in the chunk (start values of identifiers, thenumber of identifiers, the range of identifiers, etc.) when performingchunk assignment as described in the above embodiment.

FIG. 7 illustrates a diagram of a process in which a specific NF returnsan assigned ID of which the use is terminated according to anembodiment.

Referring to FIG. 7, reference numeral 701 denotes an interworking nodethat may request/trigger NF services in a specific NF, and may be a UE,a RAN (base station), or another NF.

Reference numeral 702 represents an NF for providing a communicationfunction, and includes an NF defined in the 3GPP standard and a networkequipment similar thereto. If a specific NF is implemented/operated inthe form of an instance, the NF may be replaced with an NF instance. TheNF may be replaced with an NF service in the case of the operation inunits of NF services, instead of implementation/realization in units ofNFs.

An ID management server 703 is a server providing a function of managingan identifier pool of all NFs. The ID management server 703 may beconfigured as a separate function (NF), or may be configured as adetailed function provided by the context server while being integratedwith the context server described in the above embodiment. The IDmanagement server 703 may be configured for each specific NF set, or maybe configured to support multiple NF sets.

Step 730 means that the interworking node (UE/RAN/NF) 701 and the NF 702are in the state capable of exchanging messages with each other andperforming interworking operations.

In step 735, the UE or interworking NF 701 makes a request to the NF 702for an NF service. The request for an NF service by the interworking NF701 may be made in the process of processing a service by a request of aUE, a request of a RAN, or the internal operation of an NF and a requestby another NF. In this case, the requested service is characterized inthat the use of a specific temporary identifier is terminated, and theuse of the identifiers, such as an M-TMSI (or 5G-GUTI) during ade-registration process, a GTP TEID and an IP address during a sessionrelease process, and the like, may also be terminated. Use of thetemporary identifiers and deletion of the context may be performed afterthe lapse of a predetermined time, instead of immediately performing thesame, depending on the implementation/configuration.

In step 740, the NF 702 processes the received transaction anddetermines whether or not the temporary identifier needs to be returned.Step 735 does not necessarily precede step 740, and if an ID is requiredto be returned when a timer expires or in the general operationsituation, the NF 702 may start from step 740.

In step 745, the NF 702 may transmit a request for returning the ID tothe ID management server 703. In this case, the NF 702 may make arequest to the ID management server 703 for chuck return of a temporaryidentifier to be assigned to the UE (subscriber). The request messagemay include a chunk identifier of the temporary identifier to be used.If management of IDs is performed simultaneously with management ofcontext, the return of the temporary identifier assigned to a specificUE (subscriber) may be made simultaneously with deletion of the contextfor the specific UE (subscriber). If the ID management server 703supports services of a UDSF, the request/response may be processed usingthe services described in the above embodiment in FIG. 2, and theassignment of the ID chunk may be implemented through an operation ofdeleting specific context. Alternatively, a separate service for makingan explicit request to the UDSF for deletion of the ID may be used.

The ID management server 703 switches to the state in which therequested temporary identifier is no longer used in step 750, and the IDmanagement server 703 transmits, to the NF 702, a response to the returnin step 755. If the ID is returned through processing of context, the IDmanagement server 703 may transmit a response to deletion of context.

In step 760, the NF 702 processes the remaining procedures/transactions.

In step 765, a notification of deletion of the temporary identifier istransmitted to the node (the UE/base station or the interworking NF) 701through the procedure of processing.

FIG. 8 illustrates a diagram of a method of selecting a target NF inconsideration of the capacity of an NF receiving context when providinga service by exchanging context between context storages or NFsaccording to an embodiment.

Referring to FIG. 8, a context storage 801 represents a function ofstoring/transmitting data (UE context) created/managed by an NF in orderto provide a communication service, and includes a CTSF, a UDSF, and thelike. A network repository function (NRF)/service communication proxy(SCP) 802 is an NF that assists discovery, selection, and messagerouting for providing services between NFs using connection informationand status information between NFs.

In step 810, the context storage 801 may start a new service, or maychange status.

In step 820, the context storage 801 may newly register its owninformation (NF profile) in the NRF/SCP 802, or may update the same(when the status/configuration is changed). In this case, the profile ofthe context storage 801 may include at least one of the maximum capacitythat can be provided by the context storage, the current load status,and the throughput representing the number of contexts that can beprocessed (transmitted/received) during a unit time, the size of thecontext that can be stored by one transaction, and the like. In the casewhere the profile of the context storage 801 represents the maximumcapacity, the load status, the throughput, and the size, the profile maybe expressed using a relative value calculated based on the maximumvalue. Alternatively, the maximum capacity, the load status, thethroughput, and the size may be expressed as absolute values. Forexample, the maximum capacity may be expressed as a combination of aspecific context type (e.g., SM context) and the maximum number ofacceptable contexts, and the number of contexts that can be processed ata time may be expressed as a combination of a specific context type andthe maximum number of processible contexts. For the operation in step820, the context storage 801 may transmit, to the NRF/SCP 802, a messagesuch as an “NRRegister request” or an “NFUpdate request”.

In step 830, the NRF/SCP 802 may store the capacity, the statusinformation, and the like (the NF profile) received from the contextstorage 801.

In step 840, if the NF 803 has insufficient information stored, anotherNF (SMF, AMF, etc.) 803 may transmit, to the NRF/SCP 802, adiscovery/selection request of the context storage in order to make arequest for storing and transmitting context. The discovery/selectionrequest may include information stating that the NF service to berequested is storage of context (context create, update, or push) ortransmission thereof (context transfer) even though the explicit targetto be discovered is the context storage (the CTSF or the UDSF). Therequest in step 840 may be an “NFDiscovery request message”.

In step 850, the NRF/SCP 802 may select the context storage (or a set ofcandidates) 801 according to the request, and may transmit, to the NF803 that made a request, a response thereto in step 860. In this case,the response may include necessary information (a combination of theidentifier, access address, maximum capacity, current load status,throughput, simultaneous transmission capability, and the like of thecontext storage) among the NF profile of the context storage 801, whichis received and stored in step 820, and the configuration and meaning ofthe detailed information may be the same as those described in step 820above. The response transmitted in step 860 may be an “NFDiscoveryresponse message”.

In step 870, the NF 803 may store the information received in step 860,and if a response capable of specifying one context storage is received,the NF 803 may select the corresponding context storage. In addition, ifcandidates of multiple context storages to be a target are received, theNF 803 may select one of the candidates. In this case, when performingthe selection, the NF 803 may select the context storage 801 capable ofeffectively providing services in consideration of the information (themaximum capacity, the load status, etc.) received in step 860. Even whenthe NF 803 requests context-related services to the selected contextstorage 801, the information received in step 860 may be considered. Inparticular, when the context storage 801 provides a limited amount oftransmission, the NF 803 may create a request so as not to exceed theamount of transmission, and may create a request such that the size ofthe context (the number of contexts, the size of the context, etc.)included in the request does not exceed the limit.

In step 880, the NF 803 transmits a service request to the contextstorage 801. Thereafter, the NF 803 receives a response as a result ofprocessing from the context storage 801, and another procedure may betriggered, of which a detailed description will be omitted in theembodiment. In step 880, the NF 803 may transmit, to the context storage801, a CTSF service request message for the service request.

FIG. 9 illustrates a diagram of a method of managing context in an NFaccording to an embodiment.

Referring to FIG. 9, in step 910, NFs 903 and 904 and a context storageNF 901 may perform registration, discovery, and selection processes torequest/receive mutual service provision.

In step 920, NF #1 (903) may determine that an NF change operation isrequired.

In step 930, NF #1 (903) transmits context to the context storage(CTSF/UDSF) 901, and transmits a service request for changing the NF.The service used in this case may be a service context push request, andthe request message may include at least one of an identifier (contextID) capable of identifying the target context for context transfer andchange of an NF, the type of context, an identifier of a target UE(subscriber), and an identifier of a target PDU session (if the contexttype is SM context). If the operation of the request to be transmittedto the context storage 901 includes changing the NF, as well as storingthe context, the request message may further include an identifier ofthe NF to be changed. In this case, in order to select the NF to bechanged, if backup NFs are pre-configured, NF #1 (903) may select one ofthe backup NFs. Otherwise, NF #1 (903) may select an NF from the same NFset. If the NF is not required to be changed, step 960 and stepssubsequent thereto may not be performed.

In step 940, the context storage 901 stores the context according to therequest, and transmits, to the NF #1 (903), a response thereto in step950. If a request for changing the NF is further requested in step 930,the response in step 950 to the service request received in step 930 maybe transmitted after receiving the result of changing the NF (step 980).The response in step 950 may be a service context push response.

In the case where the context storage 901 receives a service requestincluding the change of an NF in step 930, the context storage 901transmits the context to the target NF (NF #2) 904 to be changed in step960. The service used in this case may be a service context pushrequest, and the request message may include at least one of anidentifier (context ID) capable of identifying the target context forcontext transfer and change of the NF, the type of context, anidentifier of a target UE (subscriber), and an identifier of a targetPDU session (if the context type is SM context). In addition, therequest message may include information indicating whether or not thecontext push service request is intended for context storage or whetheror not the context push service request includes change of an NF.

The NF #2 (904) may store the received context in step 970, and maytransmit a response as a result thereof to the context storage 901 instep 980. In this case, the response message in step 980 may be aservice context push response. Then, in step 990, NF #2 (904) performsother procedures/transactions according to reception of context andchange of an NF. The order of steps 970, 980, and 990 may be changedwith each other.

Table 1 below shows the type and structure of the context when the NFfor transmitting and receiving context is an AMF in an embodiment.

TABLE 1 Category Services Description Data key AMContext AMF ContextIdentifies an Access & Mobility SUPI Transfer Management Context thatmay be transferred from a Source to a target AMF directly, or via thecontext storage (e.g., CTSF)

As shown in Table 1, the AM context refers to the contextcreated/managed by an AMF, and denotes data that is shared between AMFs,transmitted and received directly for changing an AMF, or transmittedthrough a context storage (CT SF). A data key for managing and browsingthe AM context and indicating a specific AM context represents theidentifier of a subscriber (SUPI).

FIG. 10 illustrates a diagram of a method for preventing malfunction andoverload due to context transfer and change of an NF according to anembodiment.

Referring to FIG. 10, in step 1010, an NF 1001 may perform a process ofdiscovering/selecting another NF 1002.

In step 1020, NF #1 (1001) determines that context transfer to anotherNF (NF #2) 1002 is required or that an NF is required to be changedalong therewith, and in step 1030, NF #1 (1001) makes a request to atarget NF (NF #2) 1002 for a context push service. The messagerequesting the context push service may include at least one of anidentifier (context ID) capable of identifying the target context forcontext transfer and change of an NF, the type of context, an identifierof a target UE (subscriber), and an identifier of a target PDU session(if the context type is SM context). In addition, the request messagefor a context push service may include information indicating whether ornot the context push service request is intended for context storage orwhether or not the context push service request includes changing an NF.The request message may be a service context push request.

In step 1040, NF #2 (1002) may store the received context, and if the NFis required to be changed, may perform other procedures/transactionsaccording to change of the NF.

In step 1050, NF #2 (1002) transmits a result of the service request toNF #1 (1001), and the response message may include information on thecurrent load status of the NF and information for processing thecontext, as well as the result. More specifically, the response messagemay include at least one of the maximum capacity that can be provided byNF #2 (1002), the current load status, and the throughput indicating thenumber of contexts that can be processed (transmitted/received) during aunit time, and the size of the context that can be stored through asingle transaction. The response message may be a service context pushresponse. In addition, NF #1 (1001) receiving the response may store theinformation included in the response, and may consider the informationwhen selecting a target or requesting processing of context in the casewhere context transfer or change of an NF is required in the future.

FIG. 11 illustrates the detailed operation of an AMF according to anembodiment. In this embodiment, it is assumed that a pre-operation fortransmitting the context of a UE to another SMF is triggered by aspecific SMF.

Referring to FIG. 11, in step 1110, an AMF receives, from an SMF(referred to as an “old SMF”), a message indicating that it is necessaryto transmit the context for a specific UE and session to another SMF.This message may be “Nsmf_PDUSession_SMContextStatusNotify”, and inorder to receive the message, the AMF may perform subscription to theold SMF in advance in order to receive a notification of a change instatus.

In step 1120, the AMF may select a target SMF (referred to as a “newSMF”) using the information contained in the request message from theSMF. In addition, the AMF may transmit, to the new SMF, a request forreceiving the context for the target UE and session from the old SMF.The message used in this case may be “Nsmf_PDUSession_CreateSMContextrequest”.

In step 1130, the AMF may optionally start a timer for determiningwhether or not the session-related context transmission of the SMF andprocessing thereof are successful.

If a timer is set in step 1130, and if a response is not received fromthe new SMF until the set timer expires, the AMF may determine that thecontext processing procedure requested to the new SMF has failed in step1140. Alternatively, if the AMF explicitly receives, from the new SMF, amessage indicating that the context processing procedure has failed, theAMF may recognize that the procedure has failed. Alternatively, the AMFmay recognize whether or not the procedure is successful throughimplementation inside the AMF or a method of receiving information fromother NFs or OAM.

If it is determined that the context process requested to the new SMFhas failed, the AMF may determine that a corresponding session has beenreleased, and may perform a procedure of releasing a PDU session in step1150. Alternatively, the AMF may inform the old SMF that the contextprocessing has failed, so that the old SMF may perform subsequentprocedures.

FIG. 12 illustrates the detailed operation of an AMF according to anembodiment. In this embodiment, it is assumed that a pre-operation fortransmitting the context of a UE to another SMF is triggered by aspecific SMF.

Referring to FIG. 12, in step 1210, an AMF receives, from an SMF(referred to as an “old SMF”), a message indicating that it is necessaryto transmit the context for a specific UE and session to another SMF.This message may be “Nsmf_PDUSession_SMContextStatusNotify”, and inorder to receive the message, the AMF may perform subscription to theold SMF in advance in order to receive a notification of a change instatus.

In step 1220, the AMF may select a target SMF (referred to as a “newSMF”) using the information contained in the request message from theSMF. In addition, the AMF transmits, to the new SMF, a request forreceiving the context for the target UE and session from the old SMF.The message used in this process may be “Nsmf_PDUSession_CreateSMContextrequest”. Thereafter, the AMF may optionally start a timer fordetermining whether or not the session-related context transmission ofthe SMF and processing thereof are successful.

In step 1230, before receiving the message indicating that the contextprocessing procedure requested to the new SMF in step 1220 is completed,the AMF may receive a separate request for the corresponding UE (forexample, a context transfer request received from another AMF during theservice request or registration process or the like). In general, thismay be a request stemming from the mobility of the UE, or may be arequest caused by the occurrence of a service (transmission of a call ordata) in the UE in an idle state.

In step 1240, the AMF determines whether or not the target UE andsession include the currently changing SMF in processing the requestreceived in step 1230. More specifically, if the operation to beprocessed for the UE is a service request, the AMF determines whether ornot the currently changing SMF belongs to the SMF providing services tothe PDU sessions to be processed for the UE. If the operation to beprocessed for the UE is a context transfer request made by another AMF,the AMF determines whether or not the currently changing SMF belongs tothe SMF managing the session of the UE. If the related SMF includes thecurrently changing SMF, the process proceeds to step 1250. Otherwise,the process proceeds to step 1260.

In step 1250, the AMF delays processing of the request received in step1230 until a message indicating that a context creation process iscompleted is received from the new SMF. That is, the AMF stores therequest received in step 1230 and waits. In this step, if the AMFreceives, from the new SMF, a message informing that the contextcreation process is completed, the AMF updates the UE context (includingthe address of the SMF) according thereto and proceeds to step 1260. Ifthe AMF sets a timer in step 1220, and if the AMF does not receive aresponse from the new SMF until the set timer expires, the AMF maydetermine that the context processing procedure requested to the new SMFhas failed. Alternatively, if the AMF explicitly receives, from the newSMF, a message indicating that the context processing procedure hasfailed, the AMF may recognize that the procedure has failed.Alternatively, the AMF may recognize whether or not the procedure issuccessful through implementation inside the AMF or a method ofreceiving information from other NFs or OAM. If it is determined thatthe context process requested to the new SMF has failed, the AMF maydetermine that a corresponding session has been released, and mayprocess the request received in step 1230. Alternatively, the AMF mayinform the old SMF that the context processing has failed, so that theold SMF may perform subsequent procedures.

FIG. 13 illustrates a diagram of the configuration of a terminalaccording to the disclosure.

Referring to FIG. 13, a terminal according to an embodiment may includea transceiver 1320 and a controller 1310 that controls the overalloperation of the terminal. In addition, the transceiver 1320 may includea transmitter 1321 and a receiver 1323.

The transceiver 1320 may transmit and receive signals to and from othernetwork entities.

The controller 1310 may perform control such that the terminal performsany one of the operations described in the above embodiments. Meanwhile,the controller 1310 and the transceiver 1320 are not necessarilyimplemented as separate modules, and may be implemented as a singlecomponent in the form of a single chip. In addition, the controller 1310and the transceiver 1320 may be electrically connected. In addition, forexample, the controller 1310 may be a circuit, an application-specificcircuit, or at least one processor. Further, the operations of theterminal may be realized by providing a memory device storingcorresponding program code to any component inside the terminal.

FIG. 14 illustrates a diagram of the configuration of a network entityaccording to the disclosure.

The network entity of the disclosure encompass a network functionaccording to the implementation of a system.

Referring to FIG. 14, a network entity according to an embodiment mayinclude a transceiver 1420 and a controller 1410 that controls theoverall operation of the network entity. In addition, the transceiver1420 may include a transmitter 1421 and a receiver 1423.

The transceiver 1420 may transmit and receive signals to and from othernetwork entities.

The controller 1410 may perform control such that the network entityperforms any one of the operations described in the above embodiments.Meanwhile, the controller 1410 and the transceiver 1420 are notnecessarily implemented as separate modules, and may be implemented as asingle component in the form of a single chip. In addition, thecontroller 1410 and the transceiver 1420 may be electrically connected.In addition, for example, the controller 1410 may be a circuit, anapplication-specific circuit, or at least one processor. Further, theoperations of the network entity may be realized by providing a memorydevice storing corresponding program code to any component inside thenetwork entity.

The network entity may be any one of a base station (RAN), an AMF, anSMF, a UPF, an NF, an NEF, an NRF, a CF, an NSSF, a UDM, an AF, an AUSF,an SCP, a UDSF, a context storage, OAM, an EMS, a configuration server,and an ID management server.

It should be noted that the configuration diagrams, the diagramsillustrating examples of a method of transmitting control/data signals,the diagrams illustrating examples of operation procedures, and the likeillustrated in FIGS. 1 to 14 are not intended to limit the scope of thedisclosure. That is, the components, entities, or operation stepsdescribed in FIGS. 1 to 14 should not be interpreted as essentialelements for the implementation of the disclosure, and the disclosurecan be implemented using only some of the elements without impairing thesubject matter of the disclosure.

The above-described operations of the base station or the terminal maybe realized by providing a memory device storing corresponding programcode to any component inside the base station or the terminal device.That is, the controller of the base station or the terminal device mayread out and execute program code stored in the memory device using aprocessor or a central processing unit (CPU), thereby performing theabove-described operations.

The various components and modules of the entity, the base station, orthe terminal described herein may be operated using hardware circuits,for example, complementary metal oxide semiconductor-based logiccircuits, firmware, and hardware circuits such as a combination ofsoftware and/or hardware and firmware and/or software embedded in amachine-readable medium. For example, various electrical structures andmethods may be implemented using transistors, logic gates, andelectrical circuits such as customized semiconductors.

Although the present disclosure has been described with variousembodiments, various changes and modifications may be suggested to oneskilled in the art. It is intended that the present disclosure encompasssuch changes and modifications as fall within the scope of the appendedclaims.

What is claimed is:
 1. A method performed by an access and mobilitymanagement function (AMF) entity in a wireless communication system, themethod comprising: receiving, from a first session management function(SMF) entity, a first message to transfer a session management (SM)context to a second SMF entity; transmitting, to the second SMF entity,a second message for requesting the second SMF entity to receive the SMcontext from the first SMF entity; starting a timer upon transmittingthe second message; and receiving, from the second SMF entity, a thirdmessage as a response to the second message before expiring the timer.2. The method of claim 1, further comprising: determining that an SMcontext transfer procedure is failed in case that the timer expiresbefore receiving the third message.
 3. The method of claim 1, whereinthe first message includes information on indicating of transferring theSM context.
 4. The method of claim 1, further comprising: receiving,from a terminal, a service request message before receiving the thirdmessage; and delaying a transaction related to the SM context untilreceiving the third message.
 5. The method of claim 1, furthercomprising: receiving, from another AMF entity, a user equipment (UE)context transfer request message before receiving the third message; anddelaying a transaction related to the SM context until receiving thethird message.
 6. The method of claim 1, wherein the first messagecomprises a Nsmf_PDUSession_SMContextStatusNotify message, the secondmessage comprises a Nsmf_PDUSession_CreateSMContext request message, andthe third message comprises a Nsmf_PDUSession_CreateSMContext responsemessage.
 7. The method of claim 1, wherein the transmitting the secondmessage further comprises: selecting the second SMF entity based on thefirst message.
 8. An access and mobility management function (AMF) in awireless communication system, the AMF entity comprising: a transceiver;and a controller configured to: receive, from a first session managementfunction (SMF) entity via the transceiver, a first message to transfer asession management (SM) context to a second SMF entity, transmit, to thesecond SMF entity via the transceiver, a second message for requestingthe second SMF entity to receive the SM context from the first SMFentity, start a timer upon transmitting the second message, and receive,from the second SMF entity via the transceiver, a third message as aresponse to the second message before expiring the timer.
 9. The AMF ofclaim 8, wherein the controller is further configured to: determine thatan SM context transfer procedure is failed in case that the timerexpires before receiving the third message.
 10. The AMF of claim 8,wherein the first message includes information on indicating oftransferring the SM context.
 11. The AMF of claim 8, wherein thecontroller is further configured to: receive, from a terminal via thetransceiver, a service request message before receiving the thirdmessage, and delay a transaction related to the SM context untilreceiving the third message.
 12. The AMF of claim 8, wherein thecontroller is further configured to: receive, from another AMF entityvia the transceiver, a user equipment (UE) context transfer requestmessage before receiving the third message, and delay a transactionrelated to the SM context until receiving the third message.
 13. The AMFof claim 8, wherein the first message comprises aNsmf_PDUSession_SMContextStatusNotify message, the second messagecomprises a Nsmf_PDUSession_CreateSMContext request message, and thethird message comprises a Nsmf_PDUSession_CreateSMContext responsemessage.
 14. The AMF of claim 8, wherein the controller is furtherconfigured to: select the second SMF entity based on the first message.